`요건사실_말소등기(기타등기에관한말소)_v1.md`는 대한민국에서 `말소등기(기타등기에관한말소)`의 소가 제기되었을 때, `말소등기(기타등기에관한말소)` 사건을 법리적으로 구성하는 요건사실 항목들을 설명한 문서다. 

20년 이상 경력을 지닌 대한민국 최고의 법조인 관점에서 `요건사실_말소등기(기타등기에관한말소)_v1.md`가 
1. `말소등기(기타등기에관한말소)` 사건을 법리적으로 구성하는 요건사실 항목들을 논리적으로 법리적으로 잘 설명하고 있는지,
2. `말소등기(기타등기에관한말소)` 사건을 법리적으로 구성하는 요건사실 항목들 중 누락된 것들이 있는지,
엄격하게 평가하여 문서로 작성하라. 평가문서는 `요건사실_말소등기(기타등기에관한말소)_평가서_v1.md`로 생성하라. 


GPT 청구권 분석

물품대금 청구

사해행위취소 및 가액배상청구

임차권확인 청구

물품대금 청구

부당이득반환청구

건물인도청구

소유권이전등기말소청구

근저당권설정등기말소청구

건물철거 및 토지인도청구

---
매매대금 청구
사해행위취소 청구
임차권확인 청구
매매대금 청구
부당이득금/이득상환금 청구
건물의 명도(인도)의 소
말소등기(소유권이전등기말소) 청구
말소등기(근저당권설정등기말소) 청구
소유물방해제거/방해예방청구


---


Gemini 분석 결과

물품대금 청구
물품대금 청구
부당이득반환청구
사해행위취소 및 가액배상청구
임차권확인 청구
건물인도 청구
소유권이전등기말소 청구
근저당권설정등기말소 청구
건물철거 및 토지인도 청구

매매대금 청구
매매대금 청구
부당이득금/이득상환금 청구
사해행위취소 청구
임차권확인 청구
건물의 명도(인도)의 소
말소등기(소유권이전등기말소) 청구
말소등기(근저당권설정등기말소) 청구
토지의 인도를 구하는 소


논란거리: 소유물방해제거/방해예방청구 vs 토지의 인도를 구하는 소


GPT:
{"claim_id":"C-009","claim_title":"건물철거 및 토지인도청구","plaintiffs":["강용원"],"defendants":["박성희"],"claim_statement":"원고 강용원은 피고 박성희를 상대로 건물철거 및 토지인도청구를 주장 후보로 식별할 수 있다."}
==> {"claim_id":"C-009","claim_type":"소유물방해제거·방해예방청구"}

Gemini:
{"claim_id": "C-009","claim_title": "건물철거 및 토지인도청구","plaintiffs":["강용원"],"defendants":["박성희"],"claim_statement":"원고 강용원은 피고 박성희를 상대로 건물철거 및 토지인도청구를 주장 후보로 식별할 수 있다."}
==> {"claim_id": "C-009","claim_type": "토지의 인도를 구하는 소"}












변시 답지: (비교: Gemini 2nd)

물품대금청구 -> 김선웅 ✅
물품대금청구 -> 오민한 ✅
소이등말소청구 -> 이문호 ✅
부당이득 -> 이문호 ❌
건물철거, 토지인도 -> 박성희 ✅
부당이득 -> 박성희 ❌
근저당권설정등기말소 -> 대한은행 ✅ 
사해행위취소 -> 오민한 ✅
인도청구 -> 박광윤 ✅ (부당이득 -> 박광윤 ✅)
임차권존재확인청구 -> 윤건우 ✅

건물철거/토지인도청구 -> 이문호 (답지에는 없음)

---

변시답지 비교: GPT 2nd

물품대금청구 -> 김선웅 ✅
물품대금청구 -> 오민한 ✅
소이등말소청구 -> 이문호 ✅
부당이득 -> 이문호 ❌
건물철거, 토지인도 -> 박성희 ✅
부당이득 -> 박성희 ❌
근저당권설정등기말소 -> 대한은행 ✅
사해행위취소 -> 오민한 ✅
인도청구 -> 박광윤 ✅ (부당이득 -> 박광윤 ✅)
임차권존재확인청구 -> 윤건우 ✅

---

식별되지 못한 청구
- 이문호에 대한 부당이득 청구
- 박성희/이문호에 대한 부당이득 청구
------


Claude Opus 4.6 버전 식별

물품대금청구 -> 김선웅 ✅ (대여금 청구)
물품대금청구 -> 오민한 ✅ (대여금 청구)
소이등말소청구 -> 이문호 ✅
부당이득 -> 이문호 ✅
건물철거, 토지인도 -> 박성희 ✅
부당이득 -> 박성희 ✅
근저당권설정등기말소 -> 대한은행 ✅
사해행위취소 -> 오민한 ✅
인도청구 -> 박광윤 ✅ (부당이득 -> 박광윤 ✅)
임차권존재확인청구 -> 윤건우 ❌

부당이득 -> 오민한 (없는 것)
손해배상 -> 오민한 (없는 것)
손해배상 -> 윤건우 (없는 것) 평가: 임차권확인을 잘못 본 것
손해배상 -> 이수인 (없는 것)

----

Claue Opus 4.5 청구권 식별

물품대금청구 -> 김선웅 ✅
물품대금청구 -> 오민한 ✅
소이등말소청구 -> 이문호 ✅
부당이득 -> 이문호 ❌
건물철거, 토지인도 -> 박성희 ✅
부당이득 -> 박성희 ❌
근저당권설정등기말소 -> 대한은행 ✅ 
사해행위취소 -> 오민한 ✅
인도청구 -> 박광윤 ✅ 
부당이득 -> 박광윤 ✅
임차권존재확인청구 -> 윤건우 ✅


대여금청구 -> 오국한 
부당이득 -> 오민한 
임차권확인청구 -> 이수인

---

Gemini 재시도

물품대금청구: 강용원 -> 김선웅 ✅
물품대금청구: 강용원 -> 오민한 ✅
사해행위취소: 강용원 -> 오민한 ✅
부당이득반환: 강용원/양정숙 -> 박광윤 ✅(원고에 강용원은 없음)
건물인도: 강용원/양정숙 -> 박광윤 ✅(원고에 강용원 없음)
임차권존재: 양정숙 -> 윤건우 ✅
소이등말소: 강용원 -> 이문호 ✅
근저당설정등기말소: 강용원 -> 대한은행 ✅
건물철거토지인도: 강용원 -> 이문호 ❌ (식별 오류)
건물퇴거: 강용원 -> 박성희 ✅

부당이득반환: 강용원 -> 이문호 ❌ (식별 실패)
부당이득반환: 강용원 -> 박성희 ❌ (식별 실패)


---


연구 프롬프트

`1. stage_2_task_A_B_C_Gemini_update.yml`은 청구권을 식별하는 작업(task_B, task_C)을 지시하는 프롬프트를 기존에 비해 개선한 것이다. 지금 다루는 사건의 고객 상담 문서(client_meeting.md)와 정보화된 모든 증거문서들(evidence_all.json)을 입력받아 `1. Stage_1.yaml`을 실행하여 얻은 결과물들이 source에 존재한다. 

이제 이 결과물들 및 client_meeting.md를 이용하여 stage 2 작업을 `1. stage_2_task_A_B_C_Gemini_update.yml`을 통해 실행하여 얻은 결과물이 
- claim_identification_view.json
- claims_identified_case_type.json
- claims_identified.json
이다. 

특히 claims_identified.json과 claims_identified_case_type.json는 식별한 청구권들 및 각 청구권들이 어떤 사건 유형에 해당하는지를 판별한 결과물이다. 

그런데, 20년 이상 경력을 지닌 대한민국 최고 수준의 변호사는 현재 다루고 있는 사건에 대해 아래와 같이 청구권을 식별할 수 있다고 주장한다.
---
1. {"claim_title":"물품대금 청구","plaintiffs":["강용원"],"defendants":["김선웅"],"claim_statement":"원고 강용원은 피고 김선웅을 상대로 물품대금 청구를 할 수 있다."}

2. {"claim_title":"물품대금 청구","plaintiffs":["강용원"],"defendants":["오민한"],"claim_statement":"원고 강용원은 피고 오민한을 상대로 물품대금 청구를 할 수 있다."}

3. {"claim_title":"소유권이전등기말소 청구","plaintiffs":["강용원"],"defendants":["이문호"],"claim_statement":"원고 강용원은 피고 이문호를 상대로 소유권이전등기말소 청구를 할 수 있다."}

4. {"claim_title":"부당이득반환 청구","plaintiffs":["강용원"],"defendants":["이문호"],"claim_statement":"원고 강용원은 피고 이문호를 상대로 부당이득반환 청구를 할 수 있다."}

5. {"claim_title":"부당이득반환 청구","plaintiffs":["강용원"],"defendants":["박성희"],"claim_statement":"원고 강용원은 피고 박성희를 상대로 부당이득반환 청구를 할 수 있다."}

6. {"claim_title":"건물철거 및 토지인도 청구","plaintiffs":["강용원"],"defendants":["박성희"],"claim_statement":"원고 강용원은 피고 박성희를 상대로 건물철거 및 토지인도 청구를 할 수 있다."}

7. {"claim_title":"근저당권설정등기말소 청구","plaintiffs":["강용원"],"defendants":["대한은행"],"claim_statement":"원고 강용원은 피고 대한은행을 상대로 근저당권설정등기말소 청구를 할 수 있다."}

8. {"claim_title":"사해행위취소 청구","plaintiffs":["강용원"],"defendants":["오민한"],"claim_statement":"원고 강용원은 피고 오민한을 상대로 사해행위취소 청구를 할 수 있다."}

9. {"claim_title":"건물인도 청구","plaintiffs":["양정숙"],"defendants":["박광윤"],"claim_statement":"원고 양정숙은 피고 박광윤을 상대로 건물인도 청구를 할 수 있다."}

10. {"claim_title":"부당이득반환 청구","plaintiffs":["양정숙"],"defendants":["박광윤"],"claim_statement":"원고 양정숙은 피고 박광윤을 상대로 부당이득반환 청구를 할 수 있다."}

11. {"claim_title":"임차권확인 청구","plaintiffs":["양정숙"],"defendants":["윤건우"],"claim_statement":"원고 양정숙은 피고 윤건우를 상대로 임차권확인 청구를 할 수 있다."}
---

이 변호사가 제시하는 청구권과 claims_identified.json이 제시하는 청구권들 사이에 약간의 불일치가 존재한다. 특히, claims_identified.json에서는 '피고: 이문호'와 '피고:박성희'를 상대로 한 '부당이득반환 청구'를 제시하지 않고 있다. 그리고 claims_identified.json는 '피고: 이문호'에 대해 '원고: 강용원'이 '건물철거 및 토지인도 청구'를 제시하고 있으나 위에 언급한 변호사는 이에 대한 청구 내용은 다루지 않고 있는 것으로 보인다. 

`1. stage_2_task_A_B_C_Gemini_update.yml`를 실행한 결과와 대한민국 최고 수준의 변호사가 제시한 청구권 식별 결과에 차이가 발생한 이유는 무엇인지 매우 심도 깊게 분석하여 그 원인을 파악하라. 



























나는 현재 변호사가 사용자인 a full vertical legal ai agent를 개발 중이다. 사용자가 고객상담문서(client_meeting.md)와 증거문서들을 정리한 문서(evidence_all.json)을 업로드하면, 에이전트가 1단계부터 5단계까지 작업을 진행하여 최종적으로 원고를 대리하는 사용자(=변호사)가 작성할 소장(complaint)을 생성한다. 

1단계에서 에이전트는 `1. Stage_1.yaml`을 통해 작업을 실행하며, client_meeting.md와 evidence_all.json을 입력받아 현재 사건을 파악하고 앞으로 청구권/청구취지/청구원인을 작성할 때 필요한 제반 결과물들을 생성한다. 이 결과물들은 모두 Source에 포함되어 있다. 

2단계에서 에이전트는 `1. stage_2_task_A_B_C_Gemini.yml`을 통해 작업을 수행하여, 원고의 소 제기 시 가능한 청구권들을 식별하고, 청구권별 사건 종류를 파악한다. 결과물은 모두 Source에 존재한다. 

2단계의 task_C에서 에이전트는 task_B에서 식별한 청구권(claims)들이 어떤 '사건종류'에 해당하는지 판별한다. 판별 기준으로 'case_kinds.md'에 제시된 대한민국 민사소송의 사건 종류 구분 기준을 엄격하게 적용한다. 

그런데, task_C를 실행하고 얻은 결과물인 'claims_identified_case_type.json'을 보면, 'C-007'과 'C-008' 청구권에 대한 사건 종류가 "말소등기 청구"로 제시된다. 그런데 'case_kinds.md'에는 사건 종류로서 단순한 '말소등기 청구'가 아니라 
'말소등기'의 구체적인 종류를 제시하고 있다. '말소등기'와 관련된 사건 종류는 
- 말소등기(소유권이전등기말소) 청구
- 말소등기(소유권보존등기말소) 청구
- 말소등기(근저당권설정등기말소) 청구
- 말소등기(가등기말소) 청구
- 말소등기(지상권설정등기말소) 청구
- 말소등기(전세권설정등기말소) 청구
- 말소등기(대위에의한소유권이전등기말소) 청구
- 말소등기(토지의일부만에관하여말소등기) 청구
- 말소등기(폐쇄한등기기록에기록된등기의말소) 청구
- 말소등기(사위(詐僞)판결에의한등기의말소) 청구
- 말소등기(기타등기에관한말소) 청구
들이다. 

'C-007'과 'C-008' 청구권에 대한 사건 종류가 왜 단순하게 '말소등기 청구'로 제시되었는지 원인을 파악하라. 

# 제약조건(must follow)
- `1. Stage_1.yaml`을 실행한 결과물들을 정확히 파악하고,
- `1. stage_2_task_A_B_C_Gemini.yml`의 task_C에 해당하는 프롬프트를 면밀하게 분석하여,
- 왜 'C-007'과 'C-008' 청구권에 대한 사건 종류가 "말소등기 청구"로 단순하게 제시되었는지 원인을 파악하고,
- 정확한 사건 이름을 제시할 수 있는 개선 방안을 제시하라.






--------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------

예. 제 판단으로는 **Stage 1 프롬프트를 먼저 고치는 것이 우선**입니다. Stage 2만 손보는 방식으로도 이번 사건의 일부 불일치는 줄일 수 있으나, 그것만으로는 충분하지 않고, 다른 민사사건으로 일반화될수록 오히려 불안정성이 커질 가능성이 높습니다. 이 결론은 이번 사건에서 드러난 오류가 **청구권 추론 단계의 법률판단 오류**라기보다, 그보다 앞선 단계에서 이미 **사건행위 단위 정보가 문서 단위 metadata에 의해 오염되는 구조**에서 발생했기 때문입니다. E-006에서 event-level로는 `성수동 대지 임대차`와 `성수동 상가 매매`가 분해되어 있었지만, `evidence_indexed.json`의 문서 단위 `legal_calculation_object`는 `매매` 하나만 남겼고, 그 결과 downstream에서 임대차 fact가 매매 metadata를 상속받았습니다. 이는 Stage 1 산출물의 구조 문제이지, Stage 2의 claim-selection 규칙만의 문제는 아닙니다.

조금 더 엄밀하게 말하면, 이번 문제는 두 층으로 나뉩니다.

첫째 층은 **표현(representation) 오류**입니다.
Stage 1은 한 문서 안에 복수 사건행위가 있어도, 후반부에서 BO나 Fact에 연결되는 계산객체를 **문서당 하나의 `legal_calculation_object`**로 유지하는 방향을 택했습니다. 게다가 Task_D1은 linked evidence의 base `legal_calculation_object`만 병합하고, BO의 `Action`, `Subject`, 개별 event 정보를 사용해 새 계산필드를 만들지 말라고 명시합니다. 이 규칙 때문에 event-level 구별이 downstream에서 다시 납작해졌습니다. 이런 구조에서는 Stage 2가 아무리 정교해도, 입력 자체가 이미 “대지 임대차 fact + 건물 매매 metadata”처럼 꼬여 있으면, 후속 청구식별은 계속 오염될 위험이 큽니다.

둘째 층은 **추론(inference) 보수성**입니다.
Stage 2는 `client_meeting.md`를 중시하더라도, 최종적으로는 `source_fact_ids`를 `claim_identification_view.json.items[*].fact_id`에 앵커링하도록 강제하고, 구조화된 fact anchor가 약하면 청구를 세우지 않도록 설계되어 있습니다. 그래서 변호사처럼 여러 사실을 묶어 `부당이득반환청구`로 재구성하기보다, 구조적으로 직접 보이는 `등기말소`, `철거`, `인도`, `퇴거` 쪽으로 먼저 수렴합니다. 이 부분은 Stage 2의 문제이지만, 그 작동방식은 Stage 1 산출물의 질에 강하게 종속됩니다.

따라서 우선순위를 정하면 다음과 같습니다.

**1순위는 Stage 1 개선**입니다.
이유는 간단합니다. Stage 1이 잘못 압축한 정보를 Stage 2가 뒤에서 복원하는 방식은 본질적으로 사후보정입니다. 사후보정은 특정 사건에서는 먹혀도, 일반성을 잃기 쉽습니다. 특히 민사소송 사건은 문서 하나에 여러 법률관계가 함께 들어 있는 경우가 흔합니다. 매매계약서 하나에 임대차 특약, 담보부 인수, 사용수익 관계, 점유이전, 부담해소 조항이 같이 들어갈 수 있습니다. 이런 상황에서 문서 단위 단일 계산객체를 유지한 채 Stage 2만 더 똑똑하게 만들면, 결국 Stage 2는 매번 “이 문서의 어느 조항이 어느 event에 대응하는가”를 다시 추정해야 합니다. 그러면 구조는 점점 heuristic-heavy해지고, 사건마다 예외 규칙이 누적됩니다. 이번 사건에서 드러난 E-006 문제가 바로 그 전형입니다.

**Stage 2만 개선하는 접근은 보조수단으로는 유효하지만, 주된 해결책으로는 부적절**합니다.
왜냐하면 Stage 2가 해야 할 일은 원래 “권리구제 단위의 법률구성”이지 “오염된 event/property metadata 복원”이 아니기 때문입니다. Stage 2에 복원 로직을 계속 얹으면, 청구식별 프롬프트가 점점 Stage 1의 정규화 실패를 뒤처리하는 복구 프롬프트로 변질됩니다. 그렇게 되면 다른 사건들, 예컨대 하나의 문서에 매매와 채무인수, 일부말소, 임차권 양수, 공사대금 정산이 섞여 있는 유형에서 규칙 충돌이 더 심해질 수 있습니다. 즉, 이번 사건에서는 Stage 2가 “부당이득반환청구도 열어라”라고 지시받으면 어느 정도 보정할 수 있겠지만, 다른 사건에서는 오히려 과잉식별이나 중복식별이 늘어날 위험이 큽니다. 이것은 제 추론이지만, 현재 구조와 프롬프트 계약을 보면 상당히 강한 추론입니다.

정리하면, 질문하신 두 선택지 중에서는 다음 판단이 더 타당합니다.

**Stage 1을 먼저 개선하고, Stage 2는 그 다음에 최소한으로 보정하는 것이 바람직합니다.**
Stage 2만 손보는 것으로는 이번 사건의 특정 불일치 몇 개를 줄일 수는 있어도, 일반적 해법이 되기 어렵습니다. 반대로 Stage 1을 고치면, 이번 사건뿐 아니라 다른 사건에서도 downstream 전반의 품질이 같이 올라갑니다. `BO.json`, `Fact_Ledger_base.json`, `claim_identification_view.json`, `claims_identified.json` 전체가 더 안정해집니다.

다만 여기서 중요한 것은, **Stage 1만 고치고 Stage 2를 그대로 두면 충분하냐**는 별개의 문제입니다. 제 판단은 **아니오**입니다. Stage 1 우선이 맞지만, 최종적으로는 Stage 2도 손봐야 합니다. 이유는 Stage 2 프롬프트 자체가 현재 다음과 같은 성향을 갖고 있기 때문입니다.

하나는, 구조화된 fact anchor가 약하면 변호사식 종합구성을 잘 하지 못한다는 점입니다.
다른 하나는, `identified_claims`에 completeness 태그를 붙여 약한 후보를 유지하는 방식이라, 이번처럼 `건물철거 및 토지인도청구` 같은 청구가 후보로 남기 쉽다는 점입니다. 실제 `claims_identified.json`의 성수동 관련 청구들은 대부분 completeness 태그가 붙은 후보입니다. 즉, Stage 1이 바로잡혀도 Stage 2가 여전히 “직접 보이는 event-based remedy”를 과선호하면, 변호사가 구성하는 `부당이득반환청구` 같은 청구는 여전히 과소식별될 수 있습니다.

그래서 실무적으로는 다음 순서가 가장 합리적입니다.

**첫째, Stage 1을 고쳐 event-level 객체와 calculation 객체를 일치시키십시오.**
핵심은 문서 단위 `legal_calculation_object`를 유지하더라도, 적어도 **event candidate별 transaction/encumbrance/value sub-object**가 별도로 있어야 한다는 점입니다. E-006처럼 임대차와 매매가 섞인 문서는 문서 전체를 대표하는 하나의 계산객체가 아니라, 각 event에 귀속된 계산객체를 가져야 합니다. 이 부분이 해결되면 F-032 같은 fact가 더 이상 `transaction_type="매매"`를 상속받지 않게 됩니다.

**둘째, Stage 2는 Stage 1이 고도화된 뒤에 ‘법률구성 규칙’만 보강하십시오.**
즉, Stage 2는 데이터 복원기가 아니라, 청구구성기여야 합니다. 여기서 보강해야 할 것은 “현재 점유·사용수익·무권원 이익 귀속이 구조화되어 있으면 부당이득반환청구도 병렬적으로 검토하라”, “동일 목적물 cluster에서 등기말소청구와 부당이득반환청구, 철거·인도청구는 상호배타적으로 하나만 고르지 말고 병렬 검토하라” 같은 **claim-construction 규칙**입니다. 이것은 Stage 2의 몫이 맞습니다. 다만 그 전제가 Stage 1에서 사건행위와 계산정보가 깨끗하게 분리되어 있어야 합니다.

따라서 제 최종 답변은 다음과 같습니다.

**우선순위 측면에서는 Stage 1 프롬프트부터 개선하는 것이 맞습니다.**
이번 문제의 근원은 Stage 2의 미세한 규칙 부족보다, Stage 1 산출물의 구조적 표현 방식에 있습니다. Stage 2만 개선하는 방식은 이번 사건에 대한 사후 패치로는 가능하지만, 다른 민사사건까지 일반화하면 brittle해질 가능성이 큽니다.
다만 **최종 해결은 “Stage 1 우선 개선 + Stage 2 제한적 보정”의 2단계 접근**이어야 합니다. Stage 1이 데이터 구조를 바로잡고, Stage 2가 그 위에서 변호사식 청구 병렬구성을 더 잘 하도록 조정하는 방식이 가장 일반성과 안정성을 동시에 확보합니다.

원하시면 다음 답변에서 바로 이어서,
**“Stage 1에서 반드시 고쳐야 할 규칙 5개”와 “그 다음 Stage 2에서 최소한으로 고쳐야 할 규칙 5개”**를 구체적인 프롬프트 문장 수준으로 제안하겠습니다.




----------------------------------------------------------------------------------------------------------


두 번째 원인은, **Stage 2가 변호사식 법률구성보다 “source_fact_ids로 앵커링 가능한가”를 더 우선**하도록 되어 있다는 점입니다. 업데이트된 프롬프트는 분명 `client_meeting.md`를 1차 자료로 놓지만, 동시에 `source_fact_ids`는 반드시 `claim_identification_view.json.items[*].fact_id`에서만 뽑으라고 못 박고 있습니다. 또 `client_meeting.md`나 `client_goal.json`이 피고 범위를 보강하더라도, `claim_identification_view.json` 안에서 그 사람을 앵커링할 fact가 없으면 `identified_entry_gate`를 충족하지 못한다고 규정합니다. 즉, **원자료로부터 법률적으로 충분히 추론 가능한 청구**라도, 그 추론을 지탱할 구조화된 fact anchor가 약하면 pipeline은 그 청구를 세우기 어렵습니다. 인간 변호사는 “경매의 효력 문제 → 소유권 귀속 문제 → 무권원 점유/사용수익 → 부당이득반환”으로 넘어가지만, 이 프롬프트는 그렇게 넓게 넘어가도록 설계되지 않았습니다.  

이 점 때문에, **이문호·박성희 상대 부당이득반환청구가 누락된 이유**가 설명됩니다. 성수동 가지(branch)에서 구조화된 fact는 주로 `경매 낙찰(F-027)`, `근저당권 설정(F-028)`, `인도명령에 의한 대지 인도(F-029)`, `건물 신축(F-031)`, `대지 임대(F-032)`, `건물 매매(F-033)`입니다. 즉, 사건행위는 풍부하지만, “무권원 사용수익으로 이득을 취하였다”, “차임 상당 이득을 반환해야 한다”, “법률상 원인 없는 이득”이라는 형식의 **직접적인 이득 귀속 fact**는 구조화되어 있지 않습니다. 반면 박광윤에 대해서는 `유치권 행사하며 임대`, `계속 점유`, `유치권 소멸청구 통지` 등 점유·사용·이득과 연결되는 fact가 비교적 직접적으로 정리되어 있어서 `부당이득반환청구`가 더 쉽게 식별되었습니다. 이는 출력 구조에 기초한 제 추론이지만, 상당한 설명력을 가집니다.    

세 번째 원인은, 이 파이프라인이 성수동 부분에서 **“가장 명시적인 사건행위의 행위자에게 가장 가까운 구제수단”을 붙이는 경향**을 보인다는 점입니다. 성수동 가지의 시간축을 보면, 이문호는 경매로 대지를 취득하고(F-027), 대한은행에게 근저당권을 설정하고(F-028), 인도명령으로 대지를 인도받고(F-029), 그 위에 건물을 신축하고(F-031), 박성희에게 대지를 임대하고(F-032), 건물을 매도합니다(F-033). 따라서 모델 입장에서는 “건물을 신축한 사람 = 이문호”라는 사실이 매우 직접적이므로, 그에게 `건물철거 및 토지인도청구`를 붙이기가 쉬웠습니다. 반면 변호사는 여기서 한 걸음 더 나아가, 현재의 점유·귀속 구조를 기준으로 **박성희 상대 건물철거 및 토지인도**, 그리고 **이문호·박성희 각자에 대한 부당이득반환**으로 재배치한 것으로 보입니다. 즉, 변호사는 “누가 어떤 행위를 했는가”보다 “현재 누가 어떤 법률상 이익을 보유하는가”를 중심으로 구제를 설계했고, 파이프라인은 그 반대로 갔습니다.  

변호사는 “누가 어떤 행위를 했는가”보다 “현재 누가 어떤 법률상 이익을 보유하는가”를 중심으로 청구권을 식별
  - 인간 변호사는 “경매의 효력 문제 → 소유권 귀속 문제 → 무권원 점유/사용수익 → 부당이득반환”으로 진행되는 추론을 함
  - 예시: 현재의 점유·귀속 구조를 기준으로 건물철거/토지인도청구 및 부당이득반환 청구권 식별
결국 인간 변호사는 여러 사실을 종합하여 “권리귀속–침해상태–현존 이익”을 기준으로 청구를 재배치함
  - 이는 교의적 종합판단에 해당





또 하나 중요한 점은, 현재 Stage 2 프롬프트는 오히려 꽤 좋은 규칙을 갖고 있다는 것입니다. client_meeting.md -> client_goal.json -> claim_identification_view.json 순으로 읽고, 구조화된 party/claim/date 필드를 우선하며, 복수 원고·복수 피고는 [원고]×[피고]로 분해하라고 지시합니다. 그런데 실제 출력은 C-002/C-005에서 원고를 묶어버렸고, C-010에서는 현재 점유자 박성희보다 과거 건축자 이문호 쪽으로 청구를 붙였습니다. 즉, 이번 차이는 “프롬프트가 나빠서”만이 아니라, LLM이 프롬프트의 핵심 통제 규칙을 충분히 따르지 못한 실행 실패도 포함합니다.

변호사가 식별한 4번·5번(이문호/박성희 상대 부당이득반환청구)을 에이전트가 놓친 이유는 더 구조적입니다. 현 파이프라인은 “사건행위→청구” 방식이라서, 처분·등기·신축·임대차 같은 event는 잘 잡지만, 그 event들로부터 파생되는 병존적 구제수단 묶음은 잘 못 만듭니다. 인간 변호사는 성수동 클러스터를 보면 보통 말소계열 청구, 철거·인도 청구, 그리고 점유·사용에 따른 부당이득반환청구를 동시에 엽니다. 반면 에이전트는 성수동에서 취소/말소·퇴거·철거 쪽으로만 가고, “무단 점유·사용의 이익”을 독립 청구로 병렬 생성하지 않았습니다. 그 이유는 두 가지입니다. 첫째, 성수동 차임 시세 자료(E-005)가 event layer/BO로 올라오지 않아 금전 앵커가 사라졌고, 둘째, 박성희의 현재 점유 사실 자체도 독립 fact로 없기 때문입니다. 그래서 변호사가 보는 “점유사용이익 반환” 회로가 시스템 안에서는 열리지 않았습니다.

정리하면, 이번 차이의 성격은 네 가지로 나뉩니다. (1) 전략적·과잉포섭형 차이: C-002/C-005의 강용원 포함. (2) 명백한 false positive: C-006. (3) 잘못된 상대방·구제형태 분해: C-010/C-011. (4) 명백한 false negative: 변호사 4번·5번 부당이득반환청구 누락. 그리고 그 배후에는 identified_claims 안에 후보청구를 함께 넣는 출력정책, 문서 단위 1개 legal_calculation_object, 핵심 BO 누락, 현재 점유/이익 회로의 구조화 실패가 있습니다.

재발 방지의 핵심은 세 가지입니다. 등기부·계약서 같은 다사건 문서는 document-level 1 snapshot이 아니라 event-level structured object로 쪼개고, 상속승계·경매신청·현재점유·인도·사용이익 같은 “청구 생성에 직접 필요한 상태사실”을 BO/fact로 강제 생성하며, 하나의 property cluster에서 말소/철거·인도/부당이득을 병렬로 열어 보는 remedy-bundle validator를 별도로 두는 것입니다. 이 세 가지를 고치지 않으면, 앞으로도 인간 변호사는 하나의 성수동 클러스터에서 4개 청구를 읽는데 에이전트는 그중 일부를 후보·오식별·누락으로 분산시킬 가능성이 높습니다.











